Skip to content

Starting a new filesystem/filesystem-internal library #1780

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 12 commits into from
Jun 5, 2025
Merged

Conversation

jpolitz
Copy link
Member

@jpolitz jpolitz commented May 13, 2025

This is very much a WIP, not worth comments yet but I find keeping a PR open and up-to-date useful.

It is this, but unironically: https://xkcd.com/927/

The idea is to:

  • Pick a small set of filesystem functionality we can support across VScode extensions, Node FS, browserFS, and whatever the next not-quite-a-real-fs platform is.
  • Compile with a different filesystem-internal in different contexts (CPO will override this builtin import) that always has a consistent interface that is relatively easy to provide across contexts
  • Allow filesystem to rely on that interface to provide any Pyret-level users with the desired functionality

jpolitz added 11 commits May 13, 2025 15:04
This, but unironically: https://xkcd.com/927/

The idea is to:

- Pick a small set of filesystem functionality we can support across VScode
  extensions, Node FS, browserFS, and whatever the next not-quite-a-real-fs
  platform is.
- Compile with a different filesystem-internal in different contexts (CPO will
  override this builtin import) that always has a consistent interface that is
  relatively easy to provide across contexts
- Allow `filesystem` to rely on that interface to provide any Pyret-level users
  with the desired functionality
Also add 'buffer' npm repo to support easily polyfilled Buffer calls on the
kinds of values you get back from readFile across browser and CLI
@jpolitz jpolitz marked this pull request as ready for review June 2, 2025 21:05
@jpolitz
Copy link
Member Author

jpolitz commented Jun 2, 2025

OK, this would be good to move on merging. There's more testing that would be nice to do.

This has the API that is needed for most work in the compiler, though it's not strictly necessary to do everything in the compiler with filesystem, this does use it in some places.

It has the common-denominator things we need to do sensible filesystem stuff in the extension (with the appropriate RPC calls and fileystem-internal setup in CPO), and nicely harmonizes that.

The filesystem API itself is the thing to publicly document for students, etc, which can work across many contexts.

@jpolitz jpolitz merged commit 6953af5 into horizon Jun 5, 2025
2 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant